Tom,
I am using v4.32 and its not working. The functions work when a program is
not running but when running the g-code file I sent it doesn’t stop.
Per the files I attached before I have mapped these functions to these bit
numbers.
#define RESTARTBIT 1032
#define CYCLESTARTBIT 1033
#define FEEDHOLDBIT 1034
#define HALTBIT 1035
All of these work as they should except for using bit 1033 as a “wait
until” for tool changes “M06”.
As for the other problem, I think I found a post processor that fixes that
problem but has numerous others. So I am going to try to mend the 2 of them
together into a usable post. The one I had the problem with is a “Generic Fanuc”
and the one I just tried and seems to fix that problem is a “Enhanced Machine
Control”. But he EMC post does not work without modifications.
Dan
Sent: Friday, August 29, 2014 9:04 PM
Subject: Re: [DynoMotion] KmotionCNC not waiting for Input
Bit
Hi Dan,
The
Synchronous IO command bitswere limited to IO numbers less than 256, but later
Versions (V4.32) should work with any numbers. What Version are you
running?
Regarding
Canned Cycles: I think G98 G99 relate to something different than what you
are describing. They have to do with how the canned cycles retract in
Z. G0, G1, G81, G80 and some others are all in the same modal group.
See:
When any of those are encountered the motion mode changes to that mode and
cancels any of the other motion mode. G80 sets the motion mode to "no
motion". I think its main purpose it to force you not to forget to select
the correct motion mode. So the behavior you observe is intentional and by
design. See:
Regards
TK
| Group: DynoMotion |
Message: 10107 |
From: Tom Kerekes |
Date: 9/2/2014 |
| Subject: Re: KmotionCNC not waiting for Input Bit |
Hi Dan,
You are correct there still is a bug with Synchronous Buffered Waits with IO Bit numbers > 255. If you were to look at the Console Screen you might see error messages.
Here is a firmware patch for KFLOP. It should be used with Test Version 4.33d. Copy to the DSP_KFLOP Directory and Flash New Version then cycle power.
HTH Regards TK
From: "'Dan' engnerdan@... [DynoMotion]" <DynoMotion@yahoogroups.com>
To: DynoMotion@yahoogroups.com
Sent: Tuesday, September 2, 2014 6:44 AM
Subject: Re: [DynoMotion] KmotionCNC not waiting for Input Bit
Tom,
I am using v4.32 and its not working. The functions work when a program is
not running but when running the g-code file I sent it doesn’t stop.
Per the files I attached before I have mapped these functions to these bit
numbers.
#define RESTARTBIT 1032
#define CYCLESTARTBIT 1033
#define FEEDHOLDBIT 1034
#define HALTBIT 1035
All of these work as they should except for using bit 1033 as a “wait
until” for tool changes “M06”.
As for the other problem, I think I found a post processor that fixes that
problem but has numerous others. So I am going to try to mend the 2 of them
together into a usable post. The one I had the problem with is a “Generic Fanuc”
and the one I just tried and seems to fix that problem is a “Enhanced Machine
Control”. But he EMC post does not work without modifications.
Dan
Sent: Friday, August 29, 2014 9:04 PM
Subject: Re: [DynoMotion] KmotionCNC not waiting for Input
Bit
Hi Dan,
The
Synchronous IO command bitswere limited to IO numbers less than 256, but later
Versions (V4.32) should work with any numbers. What Version are you
running?
Regarding
Canned Cycles: I think G98 G99 relate to something different than what you
are describing. They have to do with how the canned cycles retract in
Z. G0, G1, G81, G80 and some others are all in the same modal group.
See:
When any of those are encountered the motion mode changes to that mode and
cancels any of the other motion mode. G80 sets the motion mode to "no
motion". I think its main purpose it to force you not to forget to select
the correct motion mode. So the behavior you observe is intentional and by
design. See:
Regards
TK
From:
"'Dan' engnerdan@... [DynoMotion]"
<DynoMotion@yahoogroups.com>
To: DynoMotion@yahoogroups.com
Sent: Friday, August 29, 2014 11:57
AM
Subject: [DynoMotion]
KmotionCNC not waiting for Input Bit [5 Attachments]
[Attachment(s) from Dan included below]
I configured KmotionCNC to
wait for a bit state of 1 on bit 1033 when a M06 (tool change) happens in my
g-code program. The problem is KmotionCNC doesn’t stop it keeps processing the
code line by line. I want to say it worked once with a hardware input bit but
its not with the extended virtual bit address.
Attached are all my
pertinent files (initialization, Modbus Master, homing, g-code file example).
Got any insight into this?
Additionally I have noted another problem I have with the g-code. Its seems when
a canned cycle is ended (cleared) KmotionCNC forgets any previous move G command
it had. This is a problem because the post processors I have tried all don’t
reissue the G command. In this case there was a G00 is issued before a G98, then
G80 is issued to clear the G98, then Z0.6 errors out. The G00 should be applied
to this Z0.6.
G00 Z0.2
G98 G81 X-0.94 Y-0.3 Z-0.6104 R0.01 F10.
X0.94
G80
Z0.6
Thanks,
Dan
|
|
| Group: DynoMotion |
Message: 10118 |
From: engnerdan |
Date: 9/4/2014 |
| Subject: Re: KmotionCNC not waiting for Input Bit |
Thanks, I will try that in the next couple days.
-Dan |
|
| Group: DynoMotion |
Message: 10133 |
From: Dan |
Date: 9/4/2014 |
| Subject: Re: KmotionCNC not waiting for Input Bit |
Tom,
4.33d is dead in the water on my machine. I first flashed the 4.33d flash
and my 3 C programs. Thread 2 would not start on boot up, and none of the
threads could be started from KmotionCNC. I then flashed the new DSP file
(4.33e) and still dead. Programs could be started from the C programming window
but my initialization file hung after less than a minute.
Now I am trying to go back to 4.32 but something crashed while reflashing.
So I am trying to do the recovery now. No luck as of yet.
Here are my 3 c programs, thread 1 is the initialization, thread 2 (auto
run) is the modbus, thread 3 is my homing routine.
|
|
|
|
| Group: DynoMotion |
Message: 10134 |
From: Jeremy Brown |
Date: 9/4/2014 |
| Subject: Re: KmotionCNC not waiting for Input Bit [3 Attachments] |
I was having some very odd issues running 4.33d and C code, especially when doing the PC_COMM_GET_DROS. I’d try to printf the values returned and only half
the printf command would return. The funny part was, while the X value looked fine, the Y value (trying to show as a float) had something like 50 numbers in it – and nothing else showed up; the rest of the printf and all other output didn’t show up in the
console. I killed Kmotion, restarted, and tried again – and the previous results showed up first – before the same issue happened again. It was driving me crazy – when, on a whim, I reflashed to 4.32. The flash was successful and my problems were solved.
I suppose I’ll stick to release builds for now.
Jeremy
| Group: DynoMotion |
Message: 10135 |
From: Jack Gizienski |
Date: 9/4/2014 |
| Subject: Re: KmotionCNC not waiting for Input Bit |
Funny you mention the printf problem. I couldn’t get anything to show up. From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com]
Sent: Thursday, September 04, 2014 9:44 PM
To: DynoMotion@yahoogroups.com
Subject: RE: [DynoMotion] KmotionCNC not waiting for Input Bit I was having some very odd issues running 4.33d and C code, especially when doing the PC_COMM_GET_DROS. I’d try to printf the values returned and only half the printf command would return. The funny part was, while the X value looked fine, the Y value (trying to show as a float) had something like 50 numbers in it – and nothing else showed up; the rest of the printf and all other output didn’t show up in the console. I killed Kmotion, restarted, and tried again – and the previous results showed up first – before the same issue happened again. It was driving me crazy – when, on a whim, I reflashed to 4.32. The flash was successful and my problems were solved. I suppose I’ll stick to release builds for now. Jeremy [Attachment(s) from Dan included below] 4.33d is dead in the water on my machine. I first flashed the 4.33d flash and my 3 C programs. Thread 2 would not start on boot up, and none of the threads could be started from KmotionCNC. I then flashed the new DSP file (4.33e) and still dead. Programs could be started from the C programming window but my initialization file hung after less than a minute. Now I am trying to go back to 4.32 but something crashed while reflashing. So I am trying to do the recovery now. No luck as of yet. Here are my 3 c programs, thread 1 is the initialization, thread 2 (auto run) is the modbus, thread 3 is my homing routine. |
|
| Group: DynoMotion |
Message: 10136 |
From: Tom Kerekes |
Date: 9/5/2014 |
| Subject: Re: KmotionCNC not waiting for Input Bit |
Hi Jeremy,
At one point we used a flawed technique for extracting 64-bit double values from the UserData Array that involved casting a double pointer (pD) to the 32-bit UserData Array. This method only works if the UserData Array is 64-bit aligned in
memory. V4.32 used this flawed method but it worked because the UserData Array happened to be 64-bit aligned. Here is the flawed technique used in V4.32:
int GetDROs(double *DROx, double *DROy, double *DROz, double *DROa, double *DROb, double *DROc)
{
if (DoPCInt(PC_COMM_GET_DROS,TMP)) return 1; // Var index and Cmd
*DROx=pD[TMP];
*DROy=pD[TMP+1];
*DROz=pD[TMP+2];
*DROa=pD[TMP+3];
*DROb=pD[TMP+4];
*DROc=pD[TMP+5];
}
We have changed the example to use a method that will always work regardless of memory
alignment:
int GetDROs(double *DROx, double *DROy, double *DROz, double *DROa, double *DROb, double *DROc)
{
if (DoPCInt(PC_COMM_GET_DROS,TMP)) return 1; // Var index and Cmd
*DROx=GetUserDataDouble(TMP);
*DROy=GetUserDataDouble(TMP+1);
*DROz=GetUserDataDouble(TMP+2);
*DROa=GetUserDataDouble(TMP+3);
*DROb=GetUserDataDouble(TMP+4);
*DROc=GetUserDataDouble(TMP+5);
}
If code written using the flawed technique is used with other Versions it may not work and possibly cause corrupted values like you describe.
Please check your code to see if this is the case and if so update the code.
HTH Regards TK
From: "Jeremy Brown jeremy@... [DynoMotion]" <DynoMotion@yahoogroups.com>
To: "DynoMotion@yahoogroups.com" <DynoMotion@yahoogroups.com>
Sent: Thursday, September 4, 2014 6:43 PM
Subject: RE: [DynoMotion] KmotionCNC not waiting for Input Bit
I was having some very odd issues running 4.33d and C code, especially when doing the PC_COMM_GET_DROS. I’d try to printf the values returned and only half
the printf command would return. The funny part was, while the X value looked fine, the Y value (trying to show as a float) had something like 50 numbers in it – and nothing else showed up; the rest of the printf and all other output didn’t show up in the
console. I killed Kmotion, restarted, and tried again – and the previous results showed up first – before the same issue happened again. It was driving me crazy – when, on a whim, I reflashed to 4.32. The flash was successful and my problems were solved.
I suppose I’ll stick to release builds for now.
Jeremy
From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com]
Sent: Thursday, September 4, 2014 5:55 PM
To: DynoMotion@yahoogroups.com
Subject: Re: [DynoMotion] KmotionCNC not waiting for Input Bit [3 Attachments]
4.33d is dead in the water on my machine. I first flashed the 4.33d flash and my 3 C programs. Thread 2 would not start on boot up, and none of the threads could be started from
KmotionCNC. I then flashed the new DSP file (4.33e) and still dead. Programs could be started from the C programming window but my initialization file hung after less than a minute.
Now I am trying to go back to 4.32 but something crashed while reflashing. So I am trying to do the recovery now. No luck as of yet.
Here are my 3 c programs, thread 1 is the initialization, thread 2 (auto run) is the modbus, thread 3 is my homing routine.
|
|
| Group: DynoMotion |
Message: 10137 |
From: Jeremy Brown |
Date: 9/5/2014 |
| Subject: Re: KmotionCNC not waiting for Input Bit |
Thanks for the update, Tom. When I use GET_DROs in the future, I’ll certainly do as you describe. Yes, I was doing it the old way, which to be fair, I copied
directly from your previous documentation or sample code. Glad that’s fixed!
I was using the GET_DROS method as an easy way to find out where I was in a way that made sense to me, thinking in g-code. I instead went down the path of
using ch0->dest (whilst knowing the axis was stopped) and just used the native coordinate system. When I needed to move, I moved in a relative distance by my desired amount * axis resolution, which I was getting anyway. This made my program run much faster
(I presume because I severely limited my kflop->PC communication) and made the c code much simpler to read and update.
If anyone is curious, I describe the end result here:
http://www.youtube.com/watch?v=jZLW7knSICk. Basically, I move my router around completely with c code to find 0,0,0 using the end mill as a probe.
Thanks again for the detail, Tom,
Jeremy
| Group: DynoMotion |
Message: 10138 |
From: Tom Kerekes |
Date: 9/5/2014 |
| Subject: Re: KmotionCNC not waiting for Input Bit [3 Attachments] |
Hi Dan,
Not sure why all the problems or what steps you are performing to first Flash the New Firmware then Compile/Download your programs and Flash them. You might consider merging everything into the Initialization Program so you don't need to flash your
programs into KFLOP.
I did see one issue. This code:
void StartThread (2); //Starts PLC IO Thread
appears to the compiler as a function declaration rather than a function call. If you intend this to Start Thread #2 remove the void keyword.
The Home Program won't compile because some Console Script Commands are present rather than C Code such as:
MoveRelAtVel2=-20000 42333 //MoveRel(2,-20000); // move off the limit switch slowly negative
Regards TK
From:
"'Dan' engnerdan@... [DynoMotion]" <DynoMotion@yahoogroups.com>
To: DynoMotion@yahoogroups.com
Sent: Thursday, September 4, 2014 5:55 PM
Subject: Re: [DynoMotion] KmotionCNC not waiting for Input Bit [3 Attachments]
[Attachment(s) from Dan included below]
Tom,
4.33d is dead in the water on my machine. I first flashed the 4.33d flash
and my 3 C programs. Thread 2 would not start on boot up, and none of the
threads could be started from KmotionCNC. I then flashed the new DSP file
(4.33e) and still dead. Programs could be started from the C programming window
but my initialization file hung after less than a minute.
Now I am trying to go back to 4.32 but something crashed while reflashing.
So I am trying to do the recovery now. No luck as of yet.
Here are my 3 c programs, thread 1 is the initialization, thread 2 (auto
run) is the modbus, thread 3 is my homing routine.
|
|
| Group: DynoMotion |
Message: 10139 |
From: engnerdan |
Date: 9/5/2014 |
| Subject: Re: KmotionCNC not waiting for Input Bit |
Tom,
You just answered another question I had about starting a thread. That wasn't the problem. The homing routine was honestly working for the last which I have no idea how. I figured out how to change the "MoveRelAtVel" command after an hour of banging my
head on the work bench. It would be helpful to explain the difference in the help manual between the script commands and the c commands and how to use them.
I have been holding off on combining all the c code into one file, because it's harder to screw up 3 programs than it is one.
I did got my mill back to working with 4.32 last night. I will try 4.33 again this weekend. I think it was the homing routine errors screwing things up and then it spiraled out of control from there.
-Dan
Sent from my Verizon Wireless 4G LTE smartphone
| | | | | | | |
